MySQL内存分配与管理总体上分为上中下三篇介绍,上篇中主要介绍了 InnoDB 层和 SQL 层内存分配管理器,其中InnoDB的内存分配主要依靠ut_allocator和mem_heap_allocator完成。本篇为中篇,主要介绍InnoDB的内存构成和使用,代码版本主要基于8.0.25。
【走进RDS】之MySQL内存分配与管理(中篇)
InnoDB 是 MySQL 默认的存储引擎,而提到InnoDB的内存,就绕不开Buffer Pool,该结构对性能的影响重大。但事实上InnoDB的内存消耗并不只有BP而已,其内部还有许多重要的结构(如AHI、Change Buffer、Log buffer等)也占据着不可忽视的内存空间。了解InnoDB的内存结构和使用特点对于MySQL运行期间的内存选型和使用有很大帮助。
图源:https://dev.mysql.com/doc/refman/8.0/en/innodb-architecture.html
1.Buffer Pool
1.1 数据结构
struct buf_pool_t {
...
ulint instance_no; // 缓冲池实例编号
ulint curr_pool_size; // 缓冲池实例大小
buf_chunk_t *chunks; // 缓冲池实例的物理块列表
hash_table_t *page_hash; // 页哈希表
hash_table_t *zip_hash; // 伙伴系统分配frame对应的block哈希表
UT_LIST_BASE_NODE_T(buf_page_t) free; // 空闲链表
UT_LIST_BASE_NODE_T(buf_page_t) LRU; // LRU 链表
UT_LIST_BASE_NODE_T(buf_page_t) flush_list; // flush 链表
UT_LIST_BASE_NODE_T(buf_buddy_free_t) zip_free[BUF_BUDDY_SIZES_MAX]; //伙伴分配系统空闲链表
BufListMutex free_list_mutex; // 空闲链表的互斥锁
BufListMutex LRU_list_mutex; // LRU 链表的互斥锁
BufListMutex flush_state_mutex; // flush 链表的互斥锁
BufListMutex zip_free_mutex; // 伙伴分配互斥锁
BufListMutex zip_hash_mutex;
BufListMutex chunks_mutex; // chunk mutex链表
...
}
chunk 是物理内存分配的基本单位,instance 由一块一块的 chunk 组成。每个 chunk 被切分成 block 串和 frame 串,block 串在前,frame 串在后,两者之间可能存在不圆整的内存碎片。其中 block 为控制块,包含了页面的控制信息;frame 存储了实际的数据,由 bytes 组成。
struct buf_chunk_t {
ulint size; /*!< frames[]/blocks[]的数量 */
unsigned char *mem; /*!< frame内存区域指针 */
ut_new_pfx_t mem_pfx; /*!< 监控信息 */
buf_block_t *blocks; /*!< 控制块数组 */
uint32_t chunk_no; /*! chunk号 */
UT_LIST_BASE_NODE_T(buf_page_t) chunk_page_list; /*!< chunk list根结点 */
...
};
struct buf_block_t {
buf_page_t page; // 放在第一个位置,以便于block和page进行强制转换
BPageLock lock; // frame的读写锁
byte *frame; // 实际数据
...
BPageMutex mutex; // block锁:state、io_fix、buf_fix_count、accessed
};
struct buf_page_t {
...
page_id_t id; // page id
page_size_t size; // page 大小
ib_uint32_t buf_fix_count; // 用于并发控制
buf_io_fix io_fix; // 用于并发控制
buf_page_state state; // 页状态
lsn_t newest_modification; // 最新 lsn,即最近修改的 lsn
lsn_t oldest_modification; // 最老 lsn,即第一条修改 lsn
...
}
1.2 初始化过程
BP初始化的过程和上述的各个层级的数据结构紧密相关。初始化的主线过程大致步骤可分为:BP初始化---BP isntance初始化---chunk 初始化---block初始化;此外AHI、page_hash等结构的初始化也会在此过程中完成。
// 1. 构建BP instance指针数组
buf_pool_ptr =
(buf_pool_t *)ut_zalloc_nokey(n_instances * sizeof *buf_pool_ptr);
// 2. 多线程并发初始化BP instance
for (ulint id = i; id < n; ++id) {
threads.emplace_back(std::thread(buf_pool_create, &buf_pool_ptr[id], size,
id, &m, std::ref(errs[id]))); }
// 3. AHI的初始化
btr_search_sys_create(buf_pool_get_curr_size() / sizeof(void *) / 64);
buf_pool_create() 函数负责构建每个BP instance,主要做了几件事:
7.初始化 flush 相关数据,如 Hp 指针、链表包含关系等。
static void buf_pool_create(buf_pool_t *buf_pool, ulint buf_pool_size,
ulint instance_no, std::mutex *mutex,
dberr_t &err) {
...
// 1. 构建锁信息
mutex_create(LATCH_ID_BUF_POOL_CHUNKS, &buf_pool->chunks_mutex);
mutex_create(LATCH_ID_BUF_POOL_LRU_LIST, &buf_pool->LRU_list_mutex);
...
// 2. 计算chunks数量
buf_pool->n_chunks = buf_pool_size / srv_buf_pool_chunk_unit;
chunk_size = srv_buf_pool_chunk_unit;
buf_pool->chunks = reinterpret_cast<buf_chunk_t *>(
ut_zalloc_nokey(buf_pool->n_chunks * sizeof(*chunk)));
...
// 3. 初始化各链表
UT_LIST_INIT(buf_pool->LRU, &buf_page_t::LRU);
UT_LIST_INIT(buf_pool->free, &buf_page_t::list)
UT_LIST_INIT(buf_pool->flush_list, &buf_page_t::list);
...
// 4. 初始化chunk
do {
if (!buf_chunk_init(buf_pool, chunk, chunk_size, mutex)) {
...
} while (++chunk < buf_pool->chunks + buf_pool->n_chunks);
...
// 5. 设置instance参数
buf_pool->instance_no = instance_no;
buf_pool->curr_pool_size = buf_pool->curr_size * UNIV_PAGE_SIZE;
...
// 6. 构建page_hash和locks
srv_n_page_hash_locks =
static_cast<ulong>(ut_2_power_up(srv_n_page_hash_locks));
buf_pool->page_hash =
ib_create(2 * buf_pool->curr_size, LATCH_ID_HASH_TABLE_RW_LOCK,
srv_n_page_hash_locks, MEM_HEAP_FOR_PAGE_HASH);
buf_pool->zip_hash = hash_create(2 * buf_pool->curr_size);
...
// 7. 初始化flush相关信息,如Hp指针等
for (i = BUF_FLUSH_LRU; i < BUF_FLUSH_N_TYPES; i++) {
buf_pool->no_flush[i] = os_event_create();
}
...
new (&buf_pool->flush_hp) FlushHp(buf_pool, &buf_pool->flush_list_mutex);
...
}
static buf_chunk_t *buf_chunk_init(...)
{
// 1. ut_allocator + large方式申请内存
...
if (!buf_pool->allocate_chunk(mem_size, chunk)) {
return (nullptr);
}
...
// 2. 切分block和frame
chunk->blocks = (buf_block_t *)chunk->mem;
frame = (byte *)ut_align(chunk->mem, UNIV_PAGE_SIZE);
chunk->size = chunk->mem_pfx.m_size / UNIV_PAGE_SIZE - (frame != chunk->mem);
{
ulint size = chunk->size;
while (frame < (byte *)(chunk->blocks + size)) {
frame += UNIV_PAGE_SIZE;
size--;
}
chunk->size = size;
}
...
// 3. 初始化页控制体block
for () {
buf_block_init(buf_pool, block, frame, chunk, sync_init_nolock);
UT_LIST_ADD_LAST(buf_pool->free, &block->page);
}
// 4. 注册chunk
buf_pool_register_chunk(chunk);
...
}
buf_pool->page_hash =
ib_create(2 * buf_pool->curr_size, LATCH_ID_HASH_TABLE_RW_LOCK,
srv_n_page_hash_locks, MEM_HEAP_FOR_PAGE_HASH);
buf_pool->page_hash_old = nullptr;
buf_pool->zip_hash = hash_create(2 * buf_pool->curr_size);
1.3 页面管理链表
BP 中的每个链表都是双向链表,节点类型都是 buf_block_t ,基节点中保存了首尾节点信息和链表长度等,大致结构如下图所示。
Buffer Pool 中的页面使用情况如下图所示。其中每个小方格可视为一个页,free 表示空闲页,即该页面对应的数据为空,随时可以填入新的数据;clean 表示干净页,即该页面存在数据,且该数据未被更新;dirty 表示脏页,即该页面存在数据已被更新。各个类型的页同时存在于 BP 中,它们被各个链表串起来,协同管理。
LRU优化
LRU 分为了 Old Sublist 和 New Sublist 两段,加载数据首先会加载到 Old 位置,只有当满足一定的条件时,数据才会从 Old 段转移到 New 段。当发生类似全表扫描的操作时,LRU 的淘汰就不会影响到真正的热点数据,从而保证缓存的热度。
响应时间优化
如果后续的访问时间与第一次访问的时间小于 innodb_old_blocks_time,则不将该缓存页从 Old 区域移动到 New 区域。
如果后续的访问时间与第一次访问的时间大于 innodb_old_blocks_time,则将该缓存页从 Old 区域移动到 New 区域的头部。
缓冲池中所有脏页都会挂载在 flush list 中,以等待数据落盘。在数据更改被刷入磁盘前,数据很有可能会被修改多次。数据页控制体中记录了最新修改的 lsn(newset_modification) 和最早修改的 lsn(oldest_modification)。最新加入的数据页放在链表头部,刷数据时从链表尾开始,即优先刷新最早加入的页节点。
该结构是由 5 个链表构成的二维数组,分别是 1K、2K、4K、8K 和 16K 的碎片链表,存储从磁盘读入的压缩页,引擎使用伙伴系统来管理该结构。
2. Change Buffer
图源:https://dev.mysql.com/doc/refman/8.0/en/innodb-change-buffer.html
1.相关互斥量的构建;
2.ibuf参数的初始化,包括max_size、index等相关的数据;
void ibuf_init_at_db_start(void) {
...
// 1.互斥量操作
mutex_create(LATCH_ID_IBUF, &ibuf_mutex);
...
// 2.构建root
{
buf_block_t *block;
// IBUF_SPACE_ID = 0, FSP_IBUF_TREE_ROOT_PAGE_NO = 4
block = buf_page_get(page_id_t(IBUF_SPACE_ID, FSP_IBUF_TREE_ROOT_PAGE_NO),
univ_page_size, RW_X_LATCH, &mtr);
buf_block_dbg_add_level(block, SYNC_IBUF_TREE_NODE);
// 对应的frame作为Change Buffer B+树的root
root = buf_block_get_frame(block);
}
...
// 3. 参数设置
// CHANGE_BUFFER_DEFAULT_SIZE默认是25
ibuf->max_size = ((buf_pool_get_curr_size() / UNIV_PAGE_SIZE) *
CHANGE_BUFFER_DEFAULT_SIZE) /
100;
ibuf->index =
dict_mem_index_create("innodb_change_buffer", "CLUST_IND", IBUF_SPACE_ID,
DICT_CLUSTERED | DICT_IBUF, 1);
ibuf->index->id = DICT_IBUF_ID_MIN + IBUF_SPACE_ID;
ibuf->index->table = dict_mem_table_create("innodb_change_buffer",
IBUF_SPACE_ID, 1, 0, 0, 0, 0);
...
}
3.视情况进行 merge。
static MY_ATTRIBUTE((warn_unused_result)) dberr_t
ibuf_insert_low(ulint mode, ibuf_op_t op, ibool no_counter,
const dtuple_t *entry, ulint entry_size,
dict_index_t *index, const page_id_t &page_id,
const page_size_t &page_size, que_thr_t *thr) {
...
// 1. 构建entry
ibuf_entry = ibuf_entry_build(op, index, entry, page_id.space(), page_id.page_no(),
no_counter ? ULINT_UNDEFINED : 0xFFFF, heap);
...
// 初始化游标
btr_pcur_open(ibuf->index, ibuf_entry, PAGE_CUR_LE, mode, &pcur, &mtr);
...
// 2. 插入操作
err = btr_cur_optimistic_insert(...);// 也可能是btr_cur_pessimistic_insert
block = btr_cur_get_block(cursor);
...
// pcur收尾工作,包括rec、block的清空等
btr_pcur_close(&pcur);
// 3. 视情况进行merge
}
Change Buffer 本身没有很多额外的内存申请,依赖 Buffer Pool 中的 block 进行操作。大部分都是申请一些临时的 mem_heap_t,使用完毕后立即释放,不会在内存中长时间驻留。
3. AHI
InnoDB 的索引组织结构为 btree,当查询的时候会根据条件一直索引到叶子节点。为了减少开销,InnoDB 中引入了自适应哈希索引(Adaptive Hash Index,后文简称AHI)对索引的前缀建立了一个哈希表,用来加速查询。AHI 是为那些频繁被访问的索引页而建立的,可以理解为 btree 上的索引,其中包含了多个 hash_table。初始创建的数组大小为 buf_pool_get_curr_size() / sizeof(void *) / 64,使用 malloc 分配。数组大小最终对应了 hash_table 中 cell(bucket)的总数,这个数量实际上还要进行一个质数化的处理。
3.1 数据结构
struct hash_cell_t {
void *node; /*!< 哈希链 */
};
/* The hash table structure */
struct hash_table_t {
enum hash_table_sync_t type; /*!< MUTEX/RW_LOCK/NONE. */
ibool adaptive;
ulint n_cells; /* 哈希桶数量 */
hash_cell_t *cells; /*!< bucket数组 */
ulint n_sync_obj; /* 互斥量、锁的数量 */
union {
ib_mutex_t *mutexes;
rw_lock_t *rw_locks;
} sync_obj;
mem_heap_t **heaps; // 多个part时,用于分配哈希链的内存数组,个数和n_sync_obj相关,如在page_hash中用到
mem_heap_t *heap; // 分配哈希链的内存堆
};
3.2 内存初始化
在AHI构建的时候,分成了 8 个 part,每个 part 负责不同的 bucket ,拥有各自部分的锁。构建和初始化主要分为以下几个步骤:
2.hash_table 的初始化,底层调用 ib_create(),注意这里传入的 type 是 MEM_HEAP_FOR_BTR_SEARCH,这直接决定了 hash_table 中 heap 的类型,即内存的来源。
void btr_search_sys_create(ulint hash_size) {
/* Step-1: Allocate latches (1 per part). */
btr_search_latches = reinterpret_cast<rw_lock_t **>(
ut_malloc(sizeof(rw_lock_t *) * btr_ahi_parts, mem_key_ahi));
for (ulint i = 0; i < btr_ahi_parts; ++i) {
btr_search_latches[i] = reinterpret_cast<rw_lock_t *>(
ut_malloc(sizeof(rw_lock_t), mem_key_ahi));
rw_lock_create(btr_search_latch_key, btr_search_latches[i],
SYNC_SEARCH_SYS);
}
/* Step-2: Allocate hash tablees. */
btr_search_sys = reinterpret_cast<btr_search_sys_t *>(
ut_malloc(sizeof(btr_search_sys_t), mem_key_ahi));
btr_search_sys->hash_tables = reinterpret_cast<hash_table_t **>(
ut_malloc(sizeof(hash_table_t *) * btr_ahi_parts, mem_key_ahi));
for (ulint i = 0; i < btr_ahi_parts; ++i) { // 循环调用ib_create()
btr_search_sys->hash_tables[i] =
ib_create((hash_size / btr_ahi_parts), LATCH_ID_HASH_TABLE_MUTEX, 0,
MEM_HEAP_FOR_BTR_SEARCH);
...
}
进一步地,ib_create中主要做两件事:
调用 hash_create() 创建 hash_table
初始化table->heap
4. 其他
4.1 Log Buffer
// 内存申请
static void log_allocate_buffer(log_t &log) {
...
log.buf.create(srv_log_buffer_size);
}
// 内存释放
static void log_deallocate_buffer(log_t &log) { log.buf.destroy(); }
4.2 table cache
int ha_innobase::open(const char *name, int, uint open_flags,
const dd::Table *table_def) {
...
// session级缓存
ib_table = thd_to_innodb_session(thd)->lookup_table_handler(norm_name);
...
// 全局dict_sys级缓存
ib_table = dict_table_check_if_in_cache_low(norm_name);
...
// 缓存中不存在,直接开表
ib_table = dd_open_table(client, table, norm_name, table_def, thd);
...
// m_prebuilt结构构建
m_prebuilt = row_create_prebuilt(ib_table, table->s->reclength);
...
}
1. session_table_cache
class innodb_session_t {
table_cache_t m_open_tables;
...
};
2. dict_sys->table_hash
void dict_init(void) {
...
dict_sys->table_hash = hash_create(
buf_pool_get_curr_size() / (DICT_POOL_PER_TABLE_HASH * UNIV_WORD_SIZE));
dict_sys->table_id_hash = hash_create(
buf_pool_get_curr_size() / (DICT_POOL_PER_TABLE_HASH * UNIV_WORD_SIZE));
...
}
3. dd_open_table()
dd_open_table
|->dd_open_table_one
| |->dd_fill_dict_table //create dict_table_t
| |->dict_mem_table_create // create
| {
| // dict_table_t和内部的col、locks等内存都从这个heap上面分配,DICT_HEAP_SIZE=100
| heap = mem_heap_create(DICT_HEAP_SIZE);
| ...
| table = static_cast<dict_table_t *>(mem_heap_zalloc(heap, sizeof(*table)));
| ...
| table->heap = heap;
| table->cols = static_cast<dict_col_t *>(
| mem_heap_alloc(heap, table->n_cols * sizeof(dict_col_t)));
| table->v_cols = static_cast<dict_v_col_t *>(
| mem_heap_alloc(heap, n_v_cols * sizeof(*table->v_cols)));
| table->autoinc_lock =
| static_cast<ib_lock_t *>(mem_heap_alloc(heap, lock_get_size()));
| ...
| }
|->dict_table_add_to_cache(m_table, TRUE, heap); // 添加到缓存
Server 层中的总的 table cache 和打开表数量、字段长度都有关系,每个 table cache 占据的内存从几十k ~ 几百k不等。
4.3 lock_sys_t
void lock_sys_create(ulint n_cells)
{
...
lock_sys->rec_hash = hash_create(n_cells);
lock_sys->prdt_hash = hash_create(n_cells);
lock_sys->prdt_page_hash = hash_create(n_cells);
...
}
void lock_sys_close(void) {
...
hash_table_free(lock_sys->rec_hash);
hash_table_free(lock_sys->prdt_hash);
hash_table_free(lock_sys->prdt_page_hash);
...
}
主要的内存消耗都是在 3 个 hash_table 的构造上,并且是直接调用 hash_create() 进行“裸”构造,没有涉及 heap/heaps 的初始化,所有的内存都是通过 malloc 的方式去构造。各个 hash_table 的需要的内存大小和 srv_lock_table_size 相关,其值在 InnoDB 启动时被指定:srv_lock_table_size = 5 * (srv_buf_pool_size / UNIV_PAGE_SIZE)。
4.4 os_event_t
大多数锁、互斥量的构建和初始化最终都会落到 os_event_t 的构造,但是零散的、临时的 mutex 并不会造成很大的内存压力。前文提到的在 buf_block_t 的初始化中就有大量 mutex 和 rw_lock 的初始化,其生命周期和 BP 相当,数量和 buf_block_t 相等,因此会占据很大一部分内存空间。
buf_block_init:
/** Initializes a buffer control block when the buf_pool is created. */
static void buf_block_init(
buf_pool_t *buf_pool, /*!< in: buffer pool instance */
buf_block_t *block, /*!< in: pointer to control block */
byte *frame, /*!< in: pointer to buffer frame */
buf_chunk_t *chunk, /*!< in: pointer to chunk */
bool sync_init_nolock)
{
...
mutex_create(LATCH_ID_BUF_BLOCK_MUTEX, &block->mutex); // mutex构建
...
rw_lock_create(PFS_NOT_INSTRUMENTED, &block->lock, SYNC_LEVEL_VARYING); // rw_lock构建
...
}
mutex_create
mutex_create()
|->mutex_init()
|->TTASEventMutex::init()
|->os_event_create() // 构建os_event_t
rw_lock_create
rw_lock_create()
|->pfs_rw_lock_create_func()
|->rw_lock_create_func()
|->os_event_create() // 构建os_event_t
os_event_t os_event_create() {
os_event_t ret = (UT_NEW_NOKEY(os_event()));
return ret;
}
5. 总结
BP指代innodb_buffer_pool_size,round代表分配的大小需要做圆整对齐处理、prime代表需要做质数化处理。
● BP 指定的 size 最终体现在 chunk 的内存中,实际内存和指定的 size 可能存在差异。
● 在实际的内存分配中,除了指定的 BP 大小之外,系统还会产生额外的内存,本节只是列举部分。Oracle 的分配内存的方式对用户更加友好,指定固定的内存,具体的分配在内部完成,可以很好控制内存总量。
参考
[1] https://dev.mysql.com/doc/refman/8.0/en/innodb-architecture.html
[2] https://dev.mysql.com/doc/refman/8.0/en/innodb-buffer-pool.html
[3] http://mysql.taobao.org/monthly/2021/01/06/
[4] https://www.leviathan.vip/2018/12/18/InnoDB%E7%9A%84BufferPool%E5%88%86%E6%9E%90/
[5] https://juejin.cn/post/7109811386091307039
[6] https://juejin.cn/post/6882298660965580814
[7] https://juejin.cn/post/6974389300884570149
[8] https://dev.mysql.com/doc/refman/8.0/en/innodb-change-buffer.html
[9] 《MySQL内核:InnoDB存储引擎 》Chapter 11
[10] https://juejin.cn/post/6892659139794157575
[11] https://dev.mysql.com/doc/refman/8.0/en/innodb-adaptive-hash.html
[12] https://dev.mysql.com/doc/refman/8.0/en/innodb-redo-log-buffer.html
[13] https://dev.mysql.com/doc/refman/8.0/en/memory-use.html